This is not correct in the grand scheme of things - input (just like params) is basically unknown at this level. There is no restriction for it to be an object.

On top of that, we'll just have to handle inline expressions here somehow. So we need to figure out some strategy for that.

Yes, but studio right now only accepts a JSON object so I thought we'd start but that and work our way to more coverage. Plus, the problem is not unique to parameters or input. It's true about almost anything that comes from code so we'd have to change almost everything for better coverage some time soon :)

Yeah - but for the core of the config schema it's even OK to just give up on things that we can't handle (as in - error or something). With input, context, params, etc - all of those are "slots" for user-provided content. When it comes to them handling them gracefully is table stakes.

I think that perhaps the support for those properties is not that robust in the Studio anyway. So I'd even consider drafting this PR for now - so it can act as a reminder that we have to improve the story around this. I just imagine that we'll have to make substantial changes to how this is represented in the digraph so I'm not sold on getting this in in this form as I don't think it buys us a lot right now.

When/if we decide to pull this in - it will still be 15min of work tops to reuse this work and rebase on top of whatever changes we might have on the trunk at that point.

That's fine by me. Params and input need to be handled before the new VS Code extension is released anyway, so this can wait.